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1. Introduction 



Remote Method Invocation (RMI) permet la creation et P utilisation d' applications Java distributes de 
maniere aisee. 



1.1. Applications distributes 



Une application distribute est une application dont les classes sont reparties sur plusieurs machines 
differentes. Dans de telles applications, on peut invoquer des methodes a distance. II est alors possible 
d'utiliser les methodes d'un objet qui n'est pas situe sur la machine locale. 

Deja dans le langage C, il etait possible de faire de l'invocation a distance en utilisant RPC {Remote 
Procedure Calls). RPC etant oriente "structure de donnees", il ne suit pas le modele "oriente objet". 

RMI {Remote Method Invocation) permet l'utilisation d'objets sur des JVM distantes. II va plus loin 
que RPC puisqu'il permet non seulement l'envoi des donnees d'un objet, mais aussi de ses methodes. 
Cela se fait en partie grace a la serialisation des objets (cf. cours Input/Output). II est egalement 
possible de charger le byte-code des classes dynamiquement. 

II existe une technologie, non liee a Java, appelee CORBA {Common Object Request Broker 
Architecture) qui est un standard d'objet reparti. CORBA a ete con£u par l'OMG {Object Management 
Group), un consortium regroupant 700 entreprises dont Sun. Le grand interet de CORBA est qu'il 
fonctionne sous plusieurs langages, mais il est plus lourd a mettre en place. 

RMI est un systeme d'objets distribues plus simple que CORBA. Nous ne traiterons pas ce dernier 
dans ce cours. Sachez tout de meme qu'il existe 1'IIOP {Internet InterObject Protocol) qui permet 
P interoperability entre RMI et CORBA. 

1.2.RMI 

Le but de RMI est de creer un modele objet distribue Java qui s'integre naturellement au langage Java 
et au modele objet local. Ce systeme etend la securite et la robustesse de Java au monde applicatif 
distribue. RMI permet aux developpeurs de creer des applications distributes de manieres simples 
puisque la syntaxe et la semantique reste la meme que pour les applications habituelles. 

RMI est apparu des la version 1.1 du JDK et a ete etoffe pour la version 2. 

Avec RMI, les methodes de certains objets (appeles objets distants) peuvent etre invoquees depuis des 
JVM differentes (espaces d'adressages distincts) de celles ou se trouvent ces objets, y compris sur des 
machines differentes via le reseau. En effet, RMI assure la communication entre le serveur et le client 
via TCP/IP et ce de maniere transparente pour le developpeur. 

II utilise des mecanismes et des protocoles definis et standardises tels que les sockets et RMP {Remote 
Method Protocol). Le developpeur n'a done pas a se soucier des problemes de niveaux inferieurs 
specifiques aux technologies reseaux. 

L' architecture RMI definit la maniere dont se comportent les objets, comment et quand des exceptions 
peuvent se produire, comment gerer la memoire et comment les methodes appelees passent et 
re9oivent les parametres. 

RMI preserve la securite inherente a l'environnement Java notamment grace a la classe 
RMISecurityManager et au DGC {Distibuted Gabage Collector). 
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2. Architecture RMI 



2.1. Interfaces 

L'interface est le coeur de RMI. L' architecture RMI est base sur un principe important : la definition 
du comportement et P execution de ce comportement sont des concepts separes. 

RMI permet au code qui definit le comportement et au code qui implemente ce comportement de 
rester separe et de s'executer sur des JVM differentes. La definition d'un service distant est codee en 
utilisant une interface Java. L' implementation de ce service distant est codee dans une classe. 

Par consequent, la comprehension de RMI reside dans le fait que les interfaces definissent le 
comportement et les classes definissent 1' implementation. 

RMI supporte deux types de classe qui implemented la meme interface. La premiere est 
P implementation du comportement et s'execute du cote serveur. La deuxieme agit comme un proxy 
pour le service distant et s'execute sur le client. 

Un programme client cree des appels de methodes sur le proxy, RMI envoie la requete a la JVM 
distante et la transfere a l'implementation. Toutes les valeurs de retours fournies par l'implementation 
sont retournees au proxy puis au programme client. 

2.2. Les differentes couches de RMI 

RMI est essentiellement construit sur une abstraction en trois couches. 

2.2.1. Stubs et Skeletons 

La premiere couche est celle des Stubs et Skeletons. Cette couche intercepte les appels de methodes 
lances par le client a l'interface de reference et redirige ces appels a un service RMI distant. Cette 
structure evite au programmeur de devoir communiquer explicitement avec Pobjet distant. 

2.2.2. Remote Reference Layer 

La couche suivante est la couche de reference distante. Cette couche comprend comment interpreter et 
gerer les references faites du client vers les objets du service distant. Elle permet Pobtention d'une 
reference d'objet distant a partir de la reference locale (le stub). 

Dans le JDK 1.1, cette couche connecte les clients aux objets du service distant qui sont executes et 
exportes sur un serveur. Cette connexion est unicast (point a point). 

Dans le JDK 2, cette couche a ete amelioree pour soutenir l'activation des objets du service distant en 
sommeil via la classe RemoteObject Activation. Elle assure une reference persistante vers des objets 
distants (reconnexion eventuelle). 

Ce service est assure par le lancement du programme rmiregistry. 
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2.2.3. Couche Transport 

La couche transport est basee sur les connexions TCP/IP entre les machines. Elle fournit la 
connectivity de base entre les 2 JVM. 

De plus, cette couche fournit des strategies pour passer les firewalls. Elle suit les connexions en cours. 
Elle construit une table des objets distants disponibles. Elle ecoute et repond aux invocations. 

Cette couche utilise les classes Socket et SocketServer. Elle utilise aussi un protocole proprietaire 
R.M.P. (Remote Method Protocol). 



En utilisant une architecture en couche, chaque couche peut etre augmentee ou remplacee sans affecter 
le reste du systeme. Voici un schema montrant le transfert d' informations entre chaque couche : 



MyClient. class 

f Interface distante A 




MyServer. class 

^/implementation distante^ 
V DateServerlmpl. class J 


V DateServer.class J 




Stub 
DateServerlmpl_Stub. class 


Skeleton 
DateServerlmpl_Skel. class 


Couche de reference 

distante 

Java. rmi. Naming 


Couche de reference 

distante 

Java. rmi. Naming 


Couche Transport (TCP) 


Couche Transport (TCP) 


Reseau (IP) 



2.3.Utilisation de RMI 

Nous allons voir les principales etapes necessaires a la mise en place d'un service de type RMI. 

2.3.1. L'interface 

La premiere etape consiste a creer une interface distante qui decrit les methodes que le client pourra 
invoquer a distance. 

Pour que ses methodes soient accessibles par le client, cette interface doit heriter de l'interface 
Remote. Toutes les methodes utilisables a distance doivent pouvoir lever les exceptions de type 
RemoteException qui sont specifiques a l'appel distant. 
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Cette interface devra etre placee sur les deux machines (serveur et client). 

2.3.2. L'implementation 

II faut maintenant implementer cette interface distante dans une classe. Par convention, le nom de cette 
classe aura pour suffixe Impl. 

Notre classe doit heriter de la classe java.rmi.server.RemoteObject ou de Tune de ses sous-classes. 
La plus facile d'utilisation etant java.rmi.server.UncicastRemoteObject. 

C'est dans cette classe que nous allons definir le corps des methodes distantes que pourront utiliser nos 
clients. Evidement, il est possible d'ajouter d'autres methodes mais les clients ne pourront y acceder et 
done ne pourront les utiliser. 

2.3.3. Stubs et Skeletons 

Lorsque notre client fera appel a une methode distante, cet appel sera transfere au stub. Le stub est 
done un relais du cote client. II devra done etre place sur la machine cliente. 

C'est le representant local de Pobjet distant. II « marshalise » (emballe) les arguments de la methode 
distante et les envoie dans un flux de donnees. D'autre part, il « demarshalise » (deballe) la valeur ou 
Pobjet de retour de la methode distante. II communique avec l'objet distant par 1' intermediate du 

skeleton. 

Le skeleton est lui aussi un relais mais du cote serveur. II devra etre place sur la machine servant de 
serveur. II « demarshalise » les parametres de la methode distante, les transmet a l'objet local et 
« marshalise » les valeurs de retours a renvoyer au client. 

Les stubs et les skeletons sont done des intermediaries entre le client et le serveur qui gerent le 
transfert distant des donnees. 

On utilise le compilateur rmic pour la generation des stubs et des skeletons. C'est un utilitaire fourni 
avec le JDK 

Depuis la version 2 de Java, le skeleton n'existe plus. Seul le stub est necessaire du cote client mais 
aussi du cote serveur. 





Client 




Envoie des donnees 


\ 


Serveur 






Objet local 




Objet distant 
Execution de la methode 






Envoie 


d'un message 




/ 

Envoie d'un 


message 






Stub 
Emballage des parametres 




Skeleton 
Deballage des parametres 








/ 













Invocation d'une methode distante 
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Client 




Communication vers le stub 




Serveur 






Obiet local 






Obiet distant 
Execution de la methode 






Envoie a I'objet local 






Renvoie de la valeur de retour 






Stub 
Deballage de la valeur de retour 


/ 




Skeleton 
Emballage de la valeur de retour 




^ 











Renvoie de la valeur de retour 



2.3.4. Le registre RMI 

Les clients trouvent les services distants en utilisant un service d'annuaire active sur un hote connu 
avec un numero de port connu. RMI peut utiliser plusieurs services d'annuaire, y compris Java 
Naming and Directory Interface (JNDI). 

II inclut lui-meme un service simple appele Registry (rmiregistry). 

Le registre est execute sur chaque machine qui heberge des objets distants (les serveurs) et accepte les 
requetes pour ces services, par defaut sur le port 1099. 

Un serveur cree un service distant en creant d'abord un objet local qui implemente ce service. Ensuite, 
il exporte cet objet vers RMI. Quand I'objet est exporte, RMI cree un service d'ecoute qui attend 
qu'un client se connecte et envoie des requetes au service. Apres l'exportation, le serveur enregistre 
I'objet dans le registre de RMI sous un nom public qui devient accessible de Pexterieur. 

Le client peut alors consulter le registre distant pour obtenir des references a des objets distants. 

2.3.5. Le serveur 

Notre serveur doit enregistrer aupres du registre RMI I'objet local dont les methodes seront 
disponibles a distance. Cela se fait grace a Putilisation de la methode statique bindQ de la classe 
Naming. Cette methode permet d'associer (enregistrer) I'objet local avec un synonyme dans le 
registre. L'objet devient alors disponible par le client. 

ObjetDistantlmpl od = new Obj etDistantlmpl ( ) ; 
Naming. bind ( "serveur", od) ; 

2.3.6. Le client 

Le client peut obtenir une reference a un objet distant par Putilisation de la methode statique lookupQ 
de la classe Naming. II peut ensuite invoquer des methodes distantes sur cet objet. La methode 
lookupQ sert au client pour interroger un registre et recuperer un objet distant. Elle prend comme 
parametre une URL qui specifie le nom d'hote du serveur et le nom du service desire. Elle retourne 
une reference a I'objet distant. La valeur retournee est du type Remote. II est done necessaire de 
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caster cet objet en l'interface distante implementee par Pobjet distant. En effet, le client travaille avec 
l'interface distante et non avec Pobjet distant lui-meme. 



ObjetDistant od = (Obj etDistant ) Naming . lookup ( "//172 . 16 . X. X/serveur" ) ; 



2.3.7. Lancement 

II est maintenant possible d'executer 1' application. Cela va necessiter l'utilisation de trois consoles. 

La premiere sera utilisee pour activer le registre. Pour cela, vous devez executer l'utilitaire 
rmiregistry. 

Dans une deuxieme console, executez le serveur. Celui-ci va charger 1' implementation en memoire, 
enregistrer cette reference dans le registre et attendre une connexion cliente. 

Vous pouvez enfin executer le client dans une troisieme console. 

Meme si vous executez le client et le serveur sur la meme machine, RMI utilisera la pile reseau et 
TCP/IP pour communiquer entre les JVM. 

2.3.8. Repartitions des classes 

Dans un cas concret d' application client/serveur la repartition doit se faire de la maniere suivante : 



• Le client doit avoir acces aux interfaces distantes et aux Stubs de leurs implementations. 

• Le serveur doit avoir acces aux interfaces distantes, aux implementations et aux Stubs. 



2.3.9. Schema recapitulatif 



Client 






Serveur 






Application cliente 









Application serveur 














X 













£k 


^@ 











X 

X^ Registre * 
v J 


1 











1. 


On execute rmiregistry 


2. 


On execute le Serveur 


3. 
4. 


On cree Pobjet distant 

On l'enregistre dans l'annuaire avec 


5. 


la methode Naming. bindQ 

On execute le Client 


6. 


On recherche un objet distant avec la 


7. 


methode Naming.lookupQ 

L'annuaire renvoie une reference de 


8. 


Pobjet distant 

On invoque une methode distante 


9. 


On re9oit une valeur de retour 
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3. Exemple : Serve ur de date 

Nous allons voir ici un exemple concret en suivant les etapes decrites dans le chapitre precedant. Le 
but de cette application est d'utiliser l'appel de methodes distantes avec un simple serveur de date. 
Celui-ci permet aux clients de determiner la date et Pheure du serveur. 

3.1. L'interface DateServer 

La seule methode distante necessaire a notre application est une methode qui renvoie un objet de type 
java.util.Date. On construit done notre interface de la maniere suivante : 

import j ava . rmi . Remote ; 

import j ava . rmi . RemoteException; 

import java.util.Date; 

public interface DateServer extends Remote { 
Date getDate ( ) throws RemoteException; 



Les points importants a retenir sont que notre interface etend de 1' interface Remote. Cela permet de 
conferer un comportement distant aux classes qui Pimplementeront. De plus, notre methode getDateQ 
peut lever des exceptions de type RemoteException. Si nous avions declare d'autres methodes, elles 
auraient aussi du inclure cette clause pour etre accessibles par le client. La methode getDateQ renvoie 
un objet de type java.util.Date qui implemente l'interface java.io.Serializable. Tous les objets de 
retours d'une methode distante doivent implementer cette interface pour transiter sur le reseau. 

En effet, une methode distante peut renvoyer trois types de valeur : 

• Un type primitif (boolean, int, float, . . .) 

• Un objet implementant l'interface Serializable 

• Un objet distant 



3.2. (.'implementation DateServerlmpI 



La classe DateServerlmpI implemente notre interface DateServer que nous avons declaree 
precedemment. Elle etend la classe UnicastRemoteObject qui est une sous-classe de la classe 
RemoteObject et qui permet de faire la liaison avec le systeme RMI. II faut fournir un constructeur en 
declarant qu'il peut lever des RemoteException. 

import j ava . rmi . RemoteException; 

import j ava . rmi . server . UnicastRemoteOb j ect ; 

import java.util.Date; 

public class DateServerlmpI extends UnicastRemoteObject implements DateServer { 

public DateServerlmpI ( ) throws RemoteException!} 

public Date getDate ( ) throws RemoteException { 
return new Date ( ) ; 
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C'est dans cette classe que nous definissons la methode getDateQ qui ne fait que retourner un objet de 
type java.util.Date. Cela est possible car Pobjet Date est serialisable. 



3.3.MyServer 



La classe Server va creer un objet de type DateServerlmpl. Ensuite cet objet sera enregistrer aupres 
du Registre sous le nom MyServer, via la methode rebindQ de la classe Naming. 

import j ava . rmi . Naming ; 

import j ava . rmi . RemoteException; 

public class MyServer { 

public static void main (String [ ] args) { 
try { 

DateServerlmpl ds = new DateServerlmpl () ; 

Naming . rebind ( "rmi : //localhost/MyServer" , ds ) ; 
} catch (RemoteException re) { 

re . printStackTrace ( ) ; 
} catch (Exception e) { 

e . printStackTrace ( ) ; 
} 



II est aussi possible d'utiliser la methode bindQ, mais rebindQ est plus efficace car elle peut 
reenregistrer Pobjet aupres de l'annuaire si le nom existe deja. 



3.4.MyClient 



Le client va afficher sur la console la date que lui a renvoye le serveur. Pour cela on cree un objet de 
type DateServer (notre interface) en appelant Pobjet du registre MyServer. Puis on appelle la 
methode distante getDateQ. 

import j ava . rmi . Naming ; 

import j ava . rmi . RemoteException; 

public class MyClient { 

public static void main (String [ ] args) throws RemoteException { 

new MyClient (args [0] ) ; 
} 

public MyClient (String host) { 
try { 

DateServer server = (DateServer) Naming . lookup ( "rmi : //" + host + 
"/MyServer") ; 

System. out . println ( "Date du serveur : " + server . getDate ()) ; 

} 

catch (Exception e) { 

e . printStackTrace ( ) ; 
} 
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3. 5. Compilation 



Pour utiliser javac et rmic, verifier que le chemin des executables se trouve bien dans la variable 
d'environnement PATH. 

Pour cela, faites un clic-droit sur Poste de travail puis Proprietes. Allez sur Ponglet Avance puis 
cliquez sur Variables d'environnement... Editer la variable Path et ajouter C:\...\j2sdkl.4.x\bin si 
besoin. 

3.5.1. javac 



set CLASSPATH=C: \dossier_contenant_vos_classes 

// ou cd dossier_contenant_vos_classes 

javac DateServer . Java 

javac DateServerlmpl . Java 

javac MyServer . Java 

javac MyClient . Java 



3.5.2. rmic 



set CLASSPATH=C: \dossier_contenant_vos_classes 
// ou cd dossier_contenant_vos_classes 
rmic DateServerlmpl 



Vous pouvez remarquer qu'il ne faut pas mettre Pextension .class 

De plus, vous devez specifier le nom complet des classes (avec les noms de packages). 

Deux nouvelles classes viennent d'etre creees : DateServerImpl_Stub et DateServerImpl_Skel. Ce 
sont les stubs et skeletons de notre implementation. 

3.6.Lancement 



set CLASSPATH= 


//pour 


annul 


er 


la 


va 


leur 


du 


CLASS PATH 


start rmiregis 


try 
















start Java MyS 


erver 
















Java MyClient 


localhost 















II est necessaire d'annuler la valeur du CLASSPATH lors de chargement dynamique. Ce point sera 
aborde dans un prochain chapitre. 



3.7. Repartitions des classes 



Nous allons maintenant voir comment repartir les classes entre le serveur et le client. 
Sur le poste client disposez les classes : 

• MyClient.class 

• DateServer.class 



• 



DateServerlmplStub. class 



http : //www . 1 abo-sun . com 
Ce document est la propriete de Supinfo et est soumis aux regies de droits d'auteurs 



\SW« 



rmi - Application distribuee 13/19 



Sur le poste serveur : 

• MyServer.class 

• DateServer.class 

• DateServerlmpl.class 

• DateServerlmplStub. class 
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4. Le package Java. rmi 



Nous allons maintenant voir plus en detail les differents outils fournis par le package java.rmi. 

4.1. Interface Remote 

L' interface Remote sert a identifier les interfaces dont les methodes pourront etre invoquees depuis 
une JVM distante. Chaque objet distant doit implementer cette interface directement ou indirectement. 
Seules les methodes specifiees dans une interface distante sont disponibles a distances. 

Les classes d' implementation peuvent implementer plusieurs interfaces distantes et peuvent heriter 
d'autres classes d' implementation distantes. RMI fournit quelques classes dont les objets distants 
peuvent heriter et qui facilitent la creation d'objets distants (ex : la classe UnicastRemoteObject). 



4.2.Classe UnicastRemoteObject 



La classe UnicastRemoteObject definit un objet non replique dont les references sont valides 
seulement si le processus serveur est actif. Elle fournit un support pour les references a des objets 
actifs utilisant des flux TCP/IP. 

Les objets qui exigent un comportement distant doivent etendre de RemoteObject, typiquement via 
UnicastRemoteObject. Dans le cas contraire, ils doivent alors assumer eux-memes la responsabilite 
des methodes hashCodeQ, equalsQ et toStringQ. II est done plus simple d'utiliser la classe 
UnicastRemoteObject car vous n'avez pas a definir vous meme ces methodes. 

Le constructeur par defaut utilise le port TCP 1099. II est toutefois possible d'utiliser un autre 
constructeur qui prend en parametre un int correspondant au numero de port a utiliser pour le transfert 
des paquets TCP. 

4.3. Classe Naming 

La classe Naming fournit des methodes pour enregistrer et obtenir des references a des objets distants 
dans un registre distant (comme rmiregistry). Chaque methode de la classe Naming prend comme 
argument une String de type URL comprenant les parametres suivants : 

• hote correspond au nom (ou adresse IP) de la machine ou est situe le registre 

• port est le numero de port sur lequel le registre ecoute 

• nom correspond au nom sous lequel Pobjet distant est inscrit dans le registre 

Si hote est omis, il s'agira de la machine locale (localhost). II en va de meme pour le port, s'il est 
omis, ce sera le port 1099 qui sera utilise par defaut. 

II existe plusieurs fa£ons d'ecrire PURL : 

rmi://host:port/nom 

//host:port/nom 

//host/nom (forme la plus courante) 

//host (specifique a la methode UstQ) 

nom (dans ce cas on sait que le registre est execute en local sur le port 1099) 
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Nous allons voir plus en detail les methodes fournies par la classe Naming. Toutes ces methodes sont 
statiques. Elles peuvent lever des exceptions de type RemoteException s'il y a un probleme au niveau 
de la communication distante. De plus, elles peuvent aussi lever des exceptions de type 
MalformedURLException dans le cas ou PURL n'aurait pas la bonne syntaxe. 



4.3.1. bind() 



public static void bind (String name, Remote obj ) throws AlreadyBoundException, 
MalformedURLException, RemoteException 

Cette methode permet d'enregistrer un objet dans le registre en lui associant un nom. Elle prend en 
argument une String designant PURL de Pobjet et un objet de type Remote. S'il existe deja un lien 
pour cette URL dans le registre, une exception de type AlreadyBoundException sera levee. 



4.3.2. rebind() 



public static void rebind (String name, Remote obj) throws RemoteException, 
MalformedURLException 

Son utilisation est identique a la methode precedente mais elle permet d'associer un nouvel objet 
distant au nom specifie en parametre. Si ce nom etait deja associe a un objet, il sera remplace. On 
preferera utiliser cette methode plutot que la methode bindQ pour eviter les exceptions de type 
AlreadyBoundException. 



4.3.3. unbind() 



public static void unbind (String name) throws RemoteException, NotBoundException, 
MalformedURLException 

Detruit le lien entre le nom specifie en parametre et Pobjet distant dans le registre RMI. Si le lien est 
inexistant, une exception de type NotBoundException sera levee. 



4.3.4. Iist() 



public static String [] list (String name) throws RemoteException, 
MalformedURLException 

Cette methode retourne un tableau de String correspondant a la liste des noms de tous les liens vers 
des objets distants dans le registre dont PURL est specifiee en parametre. L'URL specifie est de la 
forme //hote:port. 



4.3.5. lookup() 



public static Remote lookup (String name) throws NotBoundException, 
MalformedURLException, RemoteException 

La methode lookupQ est utilisee par les clients pour obtenir une reference a un objet distant. L'objet 
retourne est de type Remote. Cette methode prend comme parametre une String correspondant a 
PURL de l'objet distant. Si le lien dans le registre n'existe pas, une exception de type 
NotBoundException sera levee. 
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4.4. Exceptions RemoteException 

RemoteException est la super-classe commune a de nombreuses exceptions, liees a la 
communication, qui peuvent survenir durant l'appel d'une methode distante. Chaque methode d'une 
interface distante doit pouvoir lever des exceptions de type RemoteException. II faut done la declarer 
dans la clause throws de la declaration de votre methode. 

4.5. Utilisation de rmic 

rmic est le compilateur RMI, fourni en standard avec le JDK. II s'utilise de maniere similaire a javac 
a la difference pres qu'il ne faut pas specifier l'extension des fichiers. C'est lui qui permet de generer 
les stubs et les skeletons des classes d' implementations de service distant. Pour Putiliser vous devez 
vous positionner dans le dossier contenant vos fichiers. Son utilisation est la suivante : 

rmic <option> <class names> 

ou class names correspond aux noms complets des classes (sans l'extension). Si vos classes sont 
declarees dans un package, il faut le specifier : 

rmic <option> nomjoackage . nom_classe 



Voici les options disponibles 



-keep 
-keepgenerated 

-g 

-depend 

-nowarn 

-verbose 

-classpath <path> 

-d <directory> 

-J<runtime flag> 



Ne supprime pas les fichiers sources intermediates generes 

(equivalent de "-keep") 

Genere des informations de debugage 

Recompile recursivement les fichiers obsoletes 

Ne genere pas d'avertissements 

Affiche les messages sur ce que fait le compilateur 

Specifie ou trouver les fichiers classes et source d' entree 

Specifie ou placer les fichiers classes generes 

Passe des arguments a Pinterpreteur Java 
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5. Chargement dynamique de classe 

Le framework RMI inclut aussi la distribution automatique du byte-code des stubs. Dans ce cas, 
Tapplication (au niveau client ou au niveau serveur) ne necessite que ses propres classes et chaque 
interfaces distantes qu'il utilise. Les autres classes necessaires faisant partie d'un appel a une methode 
distante seront automatiquement telechargees a partir d'un serveur web (FTP ou HTTP). Cette 
operation s'effectue a travers de la classe RMIClassLoader. Si un client ou un serveur execute un 
systeme RMI et remarque qu'il doit charger une classe situee a distance, il fera automatiquement appel 
a RMIClassLoader pour effectuer ce travail. Le chargement des classes par RMI est controle par le 
parametre java.rmi.server.codebase de Pinterpreteur Java. 

Voici la syntaxe pour definir les parametres a P execution de Pinterpreteur : 

Java [ -D<PropertyName>=<PropertyValue> ] <ClassFile> 



La propriete java.rmi.server.codebase sert a indiquer l'URL ou Ton peut trouver les fichiers a 
telecharger. Si un programme s'executant sur une JVM envoie une reference d'objet a une autre JVM 
(comme valeur de retour d'une methode), cette autre JVM aura besoin de charger le fichier classe de 
cet objet. Lorsque RMI envoie l'objet par serialisation, il ajoute l'URL a cote de l'objet. RMI n'envoie 
done pas les fichiers classes avec les objets serialises. 

Si la JVM distante a besoin de charger un fichier .class pour un objet, il cherche l'URL et contacte le 
serveur qu'elle designe pour le fichier. Quand la propriete java.rmi.server.useCodebaseOnly est 
active, la JVM charge les classes, soit a un endroit specifie dans le CLASSPATH, soit a l'URL specifie 
par cette propriete. 

En utilisant plusieurs combinaisons de proprietes systeme disponibles, vous pouvez creer differentes 
configurations systeme RMI. 



Dans Pexemple du serveur de date, on peut imaginer que vous ayez place le fichier 
DateServerImpl_Stub.class correspondant au stub sur un serveur web. Si vos programmes (client ou 
serveur) ne disposent pas de ces classes dans leur CLASSPATH, ils iront les chercher a PURL que 
vous leur specifier. Pour cela, il faut taper une des commandes suivantes : 



Java -Djava . rmi . server. codebase=http : //172 . 16 . X. X/path_des_classes/ MyServer 

Si les stubs sont sur un serveur http. 

Java -Djava . rmi . server . codebase=f tp : //172 . 16 . X.X/path/ MyServer 

Si les stubs sont sur un serveur ftp 

Java -Djava . rmi . server. codebase=http : //172.16.X.X:2001/ MyServer 

Si le serveur Web ecoute sur le port TCP 2001 

Dans ces exemples, on execute le serveur mais la syntaxe est identique pour executer le client. 

Le dernier slash (/) de PUrl est obligatoire. 

L'interet d'utiliser un serveur web est de pouvoir modifier vos objets distants sans changer quoique ce 
soit sur les clients. Generalement le service web est lance sur la meme machine que le serveur RMI. 
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6. Strategie de securite 



En Java, il est possible de mettre en place une securite systeme propre a vos applications. Nous ne 
traiterons pas de sujet en detail car il sera traite dans un autre cours. Nous n'etudierons done ici que la 
securite a mettre en place pour le fonctionnement de RMI. 

Sur certains systemes le chargement dynamique de classe peut etre refuse pour des raisons de securite. 
Dans ce cas, une exception du type AccessControlException sera levee lors de Putilisation des 
methodes de la classe Naming. 

Pour pallier ce probleme, il est possible de mettre en place une strategie de securite autorisant ce 
phenomene. Cela est possible grace a la mise en place du gestionnaire de securite specifique a RMI via 
Pobjet RMISecurityManager. II verifie la definition des classes et autorise seulement le passage des 
arguments et des valeurs de retour des methodes distantes. 

Voici comment utiliser ce gestionnaire de securite : 

if (System. getSecurityManager ( ) == null) 

System. setSecurityManager (new RMISecurityManager ( ) ) ; 

On verifie que le systeme n'a pas de gestionnaire de securite (pour ne pas ecraser celui existant), puis 
on lui dit d'utiliser un objet de RMISecurityManager. 

Ces lignes de code sont a utiliser avant de faire appel au registre par Putilisation des methodes de la 
classe Naming. 

Vous pouvez utiliser ce gestionnaire de securite aussi bien du cote client que du cote serveur. Tout 
depend de la necessite de charger des classes dynamiquement. 

II vous reste maintenant a definir les differentes permissions. La solution consiste a placer vos 
differentes permissions dans un fichier texte specifique. Ce fichier sera lu lors de la creation du 
RMISecurityManager. Par convention, il porte 1' extension .policy. 

Voici un exemple de contenu pour ce fichier : 

grant { 

permission Java . security . Allpermis s ion 
} ; 

Dans cet exemple, tout est permis ! 

C'est la permission la plus simple a configurer mais aussi la plus dangereuse. 

grant { 

permission j ava . net . SocketPermission "172.16.23.32:1099", "connect"; 
J 

On accepte les connexions sur le port 1099 de la machine dont l'adresse IP est 172.16.23.32 

Pour lire ce fichier, vous devez dire a Pinterpreteur ou il peut le trouver. Cela se fait en utilisant le 
parametre java.security.policy. Ce parametre sera combine avec java.rmi.server.codebase. 

C:\...\> Java -Dj ava . security . policy=path\f ichier . policy 

-Dj ava . rmi . server . codebase=http : //serveur : port/path/ ClassAExecuter 

Votre programme sait maintenant ou trouver le by tec ode des stubs et s'il a le droit de le recuperer. 
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7. Distributed Garbage Collector 

RMI fournit un ramasse miette distribue. Son interet est le meme que le Garbage Collector local. 

II sert a supprimer les objets distants qui ne sont plus references par des clients. II est active lorsque 
plus aucun client ne possede de souche (stub) de Pobjet distant. 

II est base sur un systeme de compteur de reference des souches et sur 1' interaction des Garbage 
Collector cote client et cote serveur. 

Lorsqu'un ramasse miette supprime une souche cela entraine la decrementation du compteur de 
reference du serveur. Si le compteur est a 0, le Garbage Collector du serveur supprime Pobjet. 

II est possible de signaler aux objets qu'ils ne sont plus references. Pour cela ils doivent implementer 
1' interface Unreferenced. Dans ce cas, ils doivent implementer la methode unreferencedQ. Celle-ci 
sera appelee avant la destruction de Pobjet. C'est le meme principe que pour Pappel de la methode 
flnalizeQ pour un objet standard. 



import j ava . rmi . * ; 
import Java rmi . server . * ; 

public class ObjetDistantlmpl extends UnicastRemoteObjet implements Obj etDistant, 
Unreferenced { 

public ObjetDistantlmpl ( ) throws RemoteException { 
} 

public void unreferenced ( ) { 

System. out . println ( "L ' objet n'est plus reference."); 
} 

public void methodeDistante ( ) { 
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